Info-Atari16 Digest Friday, August 25, 1989 Volume 89 : Issue 415 This weeks Editor: Bill Westfield Today's Topics: Re: PC-DITTO questions News from PC MAGAZINE Editor's Day Re: Atari GEMVDI programming Re SYSTEM2 Re: Multitasking Re: Hard drive questions Re: Multitasking on the ST Mention of Portfolio on TV Re: Multitasking on the ST Re: Monitor/Drive info requested [PS3000] Re: Alt. ST box Re: Towards a real, somewhat compatible multiTASKING TOS ---------------------------------------------------------------------- Date: 21 Aug 89 03:07:42 GMT From: portal!cup.portal.com!Matthew_Eric_Seitz@uunet.uu.net Subject: Re: PC-DITTO questions To: info-atari16@score.stanford.edu Concerning PC Ditto II and EGA: In an exclusive COMPUTER SHOPPER interview with the project's chief engineer, Avante-Garde Systens Co-partner William Teal, it was disclosed that hardware designed to support the 64K EGA (IBM Enhanced Graphics Adapter) standard format was being tested successfully on standard Atari SC1224 color monitors in Avant-Garde's labs. - D. F. Scott, "ST Product News" COMPUTER SHOPPER, August 1989 p. 444 ------------------------------ Date: 21 Aug 89 03:25:44 GMT From: portal!cup.portal.com!Matthew_Eric_Seitz@uunet.uu.net Subject: News from PC MAGAZINE Editor's Day To: info-atari16@score.stanford.edu Last Thursday, I was at the PC MAGAZINE Editor's Day. Much to my suprise, Atari was there, too. It wasn't a big showing, they just had a table, no signs, a couple Portfolios, and some Atari people. However, one of those people was Sig Hartman, so I pumped him for a little information. He told me the ST-E was available as of last week. He didn't give me specs, but said it had more colors and stereo sound, and was compatible with the SC1224 monitor. Since my roommate is a registered developer, I called on Atari on his behalf. Unfortunately, Gale Johnson, the new Developer's Coordinator, knew nothing about the ST-E. I'll be checking in next week to see if there's any more info. Mr. Hartman also said that the TT would be shipping 4th quarter '89, probably late 4th quarter. He mentioned that it will have the ability to support multiple users running GEM programs, using STs as terminals. By the way, you may have seen an article on Moses Computers and the PromiseLAN network in ST-LOG a while back. As an employee of Moses, I can tell you it was more wrong than right. As soon as I can find out how much info I can tell, and if there's any interest, I will pass it along. -Matthew Seitz ------------------------------ Date: 20 Aug 89 17:32:09 GMT From: nis!pwcs!stag!daemon@UMN-CS.CS.UMN.EDU (Steve Yelvington) Subject: Re: Atari GEMVDI programming To: info-atari16@score.stanford.edu chrisl@fulcrum.bt.co.uk writes... > I am about to embark on the writing of a fairly major piece of programming on > a 1040 ST with Mark Williams C (I think). I am writing a windowing application > which will also have to gather data from the ST serial port. > Can anyone recommend > a) a good introductory text on programming, particularly the serial > interface and the windowing features, > b) a good reference work for the same features As an introductory text on GEM programming, I would recommend: Atari ST Application Programming Lawrence J. Pollack Eric J.T. Weber Datatech Publications Bantam Books ISBN 0-553-34397-1 If the book isn't available in the U.K., try contacting Bantam at 666 Fifth Avenue, New York NY 10103 USA. The serial interface is another matter entirely. You don't really NEED to know much about it to make it work -- the logical AUX device actually is a FIFO buffer maintained by an interrupt-driven communications routine built into TOS. All you have to do is poll the AUX device using the Cauxis/ Cauxin GEMdos calls or the equivalent Bconstat/Bconin at the BIOS level. You don't have to install your own interrupt service routines or other MS-DOS-like brain-damage-control measures. A couple of tricks: Rsconf(baud,flow,uc,rs,ts,sc) WORD baud, flow, uc, rs, ts, sc configures the RS232C port. Some legal "baud" values are: 0 == 19.2 kb 1 == 9600 2 == 4800 4 == 2400 7 == 1200 9 == 300 Values for flow are: 0 == no flow control (default) 1 == xon/xoff 2 == RTS/CTS (whether it works is another matter entirely) 3 == both xon/xoff and RTS/CTS The rest of the parameters are best left untouched unless you really want to get bizarre. To avoid changing the value of a setting, use -1. For example. Rsconf(7, -1, -1, -1, -1, -1) will set the speed to 1200 and leave the other settings unchanged. Another useful call: Iorec(iodev) WORD iodev returns a pointer to an input buffer descriptor structure, which is immediately followed by the output buffer descriptor in the same format. By poking around in these structures, you can repoint the queue to your own buffer of a larger or smaller size. Why would you want to do this? Suppose you're receiving Ymodem. As soon as you get a packet, you ACK it, THEN you start writing to disk. Since you wisely have made the input buffer > 1K, the interrupt-driven i/o routine has a place to stuff ALL of the next incoming block, even if you have very slow disk drives and a very fast modem. (I once made the mistake of trying Tom Zerucha's WXmodem (windowing xmodem) program without using his companion TSR utility to expand the input buffer ... and I was writing to a floppy disk. It was a disaster!) Here's what the structure looks like: struct iorec char *buffer; /* pointer to FIFO queue */ WORD buf_size, /* size of the FIFO queue */ buf_head, /* queue head index */ buf_tail, /* queue tail index */ buf_low, /* when to turn flow ON */ buf_hi; /* when to turn flow OFF */ If you fool around with this stuff, don't forget to restore the pointers and values before your program terminates, or the next program may get a very rude shock from the AUX port! Hope this helps. This message is in the public domain. -- Steve Yelvington, up at the lake in Minnesota ... bungia.mn.org!stag!thelake!steve ------------------------------ Date: 20 Aug 89 10:30:10 GMT From: cs.dal.ca!iisat!brains!george_seto@uunet.uu.net (George Seto) Subject: Re SYSTEM2 To: info-atari16@score.stanford.edu Re SYSTEM2: I have used your System 2 shell a little bit and would like to suggest two things. 1 - A method to determine what is the amount of space left available on the disk. 2 - The system DOESN'T change the colours on entry into it or exit from it. I am using a colour system, and the computer changes colour when it entered the System2 program, which I don't mind. However when it returns to the calling program it has changed the colours. Haven't used it much except to find out those two things. Otherwise it seems limited compared to gulam, but is almost half the size. Probably since it doesn't include the Terminal program or MicroEmacs editor which gulam has built-in. -- -===------===- From George Seto at Cerebral Cortex BBS System -==-==----==-==- (902)462-7245 3/12/2400 8N1 24h/7d -==-------==------ george_seto%brains@iisat.UUCP -==-==----==-==- ------------------------------ Date: 19 Aug 89 07:46:05 GMT From: obryan@gumby.wisc.edu (Mark O'Bryan) Subject: Re: Multitasking To: info-atari16@score.stanford.edu In article <1610@psueea.UUCP>, kirkenda@jove.cs.pdx.edu (Steve Kirkendall) writes: > > 1) Why do I want multitasking? Well, mostly because it would make desk > accessories obsolete; each DA could be replaced by an application program. > DAs use memory from the time the system is booted to the time it is rebooted. > This is bad. You have to reboot the system to install a new DA. This is bad. Actually, neither of these statements is true if you have MultiDesk from CodeHead Software. It allows you to load and flush accessories pretty much at will, without rebooting. It's a slick product. Your other points about DA limitations (omitted) were well made, and easy to agree with. -- Mark T. O'Bryan Internet: obryan@gumby.cc.wmich.edu Western Michigan University Kalamazoo, MI 49008 ------------------------------ Date: 21 Aug 89 08:38:02 GMT From: mcvax!hp4nl!ruuinf!verwer@uunet.uu.net (Nico Verwer) Subject: Re: Hard drive questions To: info-atari16@score.stanford.edu In article <8908181535.AA13948@ucbvax.Berkeley.EDU>, SQ79@liverpool.ac.UK (Mark Powell) writes: > > 2. I've heard that hard drives spin at about 3600 rpm. Therefore if your > recommended interleave factor is one, will the controller read the track > in a single revolution? If so doesn't that mean it is reading the track > in 1/3600th of a second? (This can't be right!) I know the seek and Rpm means `revolutions per _minute_', and since there are 60 seconds to one minute, and the controller reads the track in a single revolution, it reads the track in 1/60th of a second. That is 16.6ms, not 0.3ms. -- Nico Verwer @ Dept. of Computer Science, University of Utrecht, The Netherlands (verwer@cs.ruu.nl) ------------------------------ Date: 21 Aug 89 05:57:31 GMT From: mcvax!hp4nl!phigate!philmds!leo@uunet.uu.net (Leo de Wit) Subject: Re: Multitasking on the ST To: info-atari16@score.stanford.edu In article <679@opal.tubopal.UUCP> alderaan@tubopal.UUCP (Thomas Cervera) writes: |In article <1070@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: |=[] |= Whereas the 68010, 68020 etc. store much |=information on the stack at a BUSERR (29 words if I'm correct), the |=68000 only stores 7 words, which is not sufficient to resume each type |=of instruction. For instance: |= |= movem.l (a3),a2-a5 |= |=Since this instruction modifies the contents of a3, it cannot be resumed |=when a bus error occurs after a3 has been modified (and the instruction |=has not yet completed). | | I'm not that familiar with the 68000's hardware and pin configuration. |But isn't there a pin telling the non-existent MMU 'shut up, I'm working on |an instruction right now !' ? | Sure, the MMU must be able to hold it's BUSERR signal back until the CPU |drops this line and tries to fetch the next instruction. | If this is possible, error recovery on BUSERR should not be a problem. I think you missed my point. The data pointed to by a3 could lay near a page boundary. For instance a2-a3 can still be fetched, but a4 must be read in from a not (yet) existing address (which causes a BUSERR). a3 has been modified, so you cannot repeat the instruction (you have to know the original contents of a3 to do that). You could hold back the BUSERR signal, but I don't know what good that will do to you. You still have to execute the instruction. Execution of the instruction causes the BUSERR, which kicks the BUSERR exception handler to page in the new memory, after which the instruction can be restarted at the point it was interrupted (reading a value for a4 in the sample case). 68010's and 68020's etc. store enough intermediate data to resume an instruction this way, 68000's do not. The whole point is that the BUSERR exception is just the means to trigger the paging event. Leo. ------------------------------ Date: 19 Aug 89 03:06:59 GMT From: att!chinet!saj@ucbvax.Berkeley.EDU (Stephen Jacobs) Subject: Mention of Portfolio on TV To: info-atari16@score.stanford.edu Tonight's guest on Wall Street Week (PBS financial news show, hosted by Louis Rukeyser) was Lee Isgur. He mentioned that Atari had announced a pocket computer, that it would be available in time for Christmas, and that he had one in his pocket as he was talking. This man is an influential enough financial analyst that one can understand Atari buttering him up with early samples. It's encouraging to hear that there are enough machines for ANY of them to leave home. Isgur also referred to the hand-held game machine. And no, he didn't say what he thought of Atari or show any goodies. It was just something he said in passing. Steve J. ------------------------------ Date: 21 Aug 89 16:46:47 GMT From: cbmvax!daveh@uunet.uu.net (Dave Haynie) Subject: Re: Multitasking on the ST To: info-atari16@score.stanford.edu in article <679@opal.tubopal.UUCP>, alderaan@tubopal.UUCP (Thomas Cervera) says: > =The problem is that for instance a page fault can emerge whilst in the > =middle of an instruction. > I'm not that familiar with the 68000's hardware and pin configuration. > But isn't there a pin telling the non-existent MMU 'shut up, I'm working on > an instruction right now !' ? Impossible. It's the fact that the 68000's working on that instruction that caused the page fault in the first place. Page faults are caused most often on a VM system when an instruction tries to access a virtual address that isn't currently in physical memory. This always happens in an instruction; where else do you think addresses are generated? The exception takes place, the OS brings up its VM manager which proceeds to fetch the missing page, then either continue the instruction (68010-68030) or retry the instruction (68040). The 68000 doesn't save enough context for either. Though back in the old days, a pair of 68000s could be hooked up to achieve this same end (Apollo is one company that used such a scheme). > Thomas Cervera | UUCP: alderaan@tubopal.UUCP -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" We have no choice. We are, after all, professionals. ------------------------------ Date: 21 Aug 89 18:30:57 GMT From: titan!bro@rice.edu (Douglas Monk) Subject: Re: Monitor/Drive info requested [PS3000] To: info-atari16@score.stanford.edu I don't know if it was "legal" or not, but I saw one of these combined monitor and floppy drives for sale at Federated here in Houston years ago. This was long before Atari bought them, if memory serves. Doug Monk (bro@rice.edu) Disclaimer: These views are mine, not necessarily my organization's. ------------------------------ Date: 21 Aug 89 18:35:23 GMT From: titan!bro@rice.edu (Douglas Monk) Subject: Re: Alt. ST box To: info-atari16@score.stanford.edu Tech Specialties in Houston offers a CPU case that moves the motherboard, floppies, and hard drive(s) into an AT or tower type case, and puts the original keyboard into a modified (smaller) case connected by cable to the CPU. I don't have info on price or Tech Specialties' address, but they have adds in Computer Shopper last I checked, and I saw a CPU case at the World of Atari show in Dallas. Doug Monk (bro@rice.edu) Disclaimer: These views are mine, not necessarily my organization's. ------------------------------ Date: 20 Aug 89 05:27:53 GMT From: att!chinet!saj@ucbvax.Berkeley.EDU (Stephen Jacobs) Subject: Re: Towards a real, somewhat compatible multiTASKING TOS To: info-atari16@score.stanford.edu In the referenced article, David Beckemeyer repeated his offer to donate the RTX multitasking kernel to the public domain . He takes us all to task because all he requires is for someone to write a worthwhile application to go with it, and in 2 years, nobody wrote one. As I remember the earlier discussion, though, the conditions were never so clearcut before. I remember a lot of offers to make RTX available free if anyone could give him a good reason, and then a general fading out of discussion. So: somebody does a printer daemon or a shell with job control and then we can all have RTX? That's a more concrete target. Steve J. ------------------------------ End of Info-Atari16 Digest ************************** -------